Cisco Networkers 1998

home *** CD-ROM | disk | FTP | other *** search

/ Cisco Networkers 1998 / Cisco Networkers 1998.iso / pc / talks / nwk05b / nwk05b.eml < prev next >

Wrap

Text File | 1998-04-21 | 64.4 KB | 1,052 lines

<HTML> <HEAD> </HEAD> <BODY> We can now move on and talk about some traffic management techniques within ATM. And in doing so, it's important to understand why we need traffic management, and then we'll talk about some traffic control techniques. And then we'll talk about those available bit rate congestion feedback mechanisms that I mentioned previously. So, why do we need traffic management in an ATM network? Actually in any network you want to have some level of traffic management, I guess. And - but basically what you want to do in an ATM network is the actual goal is to prevent congestion from happening in the first place. So kind of like preventative maintenance on congestion. And then if congestion happens, being able to isolate it so that it only stays in one small part of the network rather than spreading to the rest of the network. Those are really the main reasons behind combating congestion. Also we have this concept that I have here written as provision for priority control. And what that means now is that basically now the buffer mechanisms and so forth will be a little bit different in an ATM switch, because now that we have this Quality of Service layer added to the whole equation it's no longer first-in, first-out of the cell switch, but rather a CBR application which comes into the - a CBR cell which comes into the switch may have higher priority than maybe a, you know, UBR cell. So it's going to - even though the UBR cell arrived first, the CBR cell would be the first one to actually traverse the switch even though it came in after that UBR cell, for example. So provisioning for priority control, and we'll talk about different mechanisms that are used for that. So when we talk about, you know, why do we need this traffic management, I think this is a good illustration of why it's needed. Essentially, the concept goes like this: if you have a 1500-byte Ethernet packet, that is chopped up into 32 53-byte cells. Now, as those cells are traversing the ATM network, if one of those cells is lost the rest are deemed useless when they reach the destination. So therefore we can get into this concept whereby we get this thing called congestion collapse. Whereby if cells are dropped randomly from different TCP/IP packets then the - all those TCP/IP packets when they get to the destination will be deemed useless, they will have to be retransmitted, that retransmission will cause more congestion, causing more drops, causing more re-transmissions, etc. So we get into this concept known as exponential congestion, or congestion collapse. That's the result of that. So this is the - cell loss is data's critical enemy when we're talking about traffic management. And we'll go into some things that - some different techniques that, you know, we'll do a quick Cisco commentary and talk about some of our special traffic control techniques, and then we'll talk about some generic ones as well. So, when we look at traffic control techniques there's really three phases that happen. The first one is the - how to control traffic during the connection setup, or the connection management. So really just the - connection management's kind of the acceptance of the call in the first place. And then we have traffic management, which has to do with policing. So, once the call is made and once the Quality of Service parameters were agreed on by both the network and the end user, making sure that the end user is actually abiding by that contract, if you will. So that's called policing, and we'll go into detail on that. And then finally we have traffic smoothing, or making the traffic look like something that it's not. So making it look smoother than it actually really is in order to abide by any traffic parameters that you have set in the network. So, when I think of this I think of the connection management as the acceptance, that's kind of like the judge, and traffic management is the policeman, and traffic smoothing would be kind of like the lawyer of these things. So, that's my little way to think of those. At any rate, this should look somewhat familiar, this traffic control techniques slide. And essentially, you know, bringing back into our talk here this concept of the end station making a contract with the ATM network using our traffic parameters that we described before. So what would happen here, for example, is we would have a workstation, who would be saying, " I want a virtual circuit. And I'll tell you want I want; I want X megabits per second, at Y delay, with Z cell loss." And he will ask that of the network. Well then the network must - the network switches must talk amongst themselves, and they do this via a protocol known as CAC, or Connection Admission Control. And what they do is, based on the request that was made from the end stations, the switches talk amounts themselves, they check their different buffer levels, and their memory buffers, and the bandwidth, per-port bandwidth, and they answer yes or no, can I accommodate this connection? And if not, they will send back a negotiating value. And so, there's this negotiation between the end station and the network, which is known as CAC, or Call Admission Control, as I said before. So now the connection is made and the user is happy, and the application is going along, and then all of a sudden there's this rebel application that comes into the network, and all of a sudden the end station is not conforming to the contract that was made before. So now this is where that policing function steps in. And that policing function is also known as Usage Parameter Control, or UPC. And what that policing function does is it says, "Hey," - and it's residing on the ingress switch into the ATM cloud - and it says, "Hey, this end station is not keeping with the traffic contract that we had laid out before." So I have a decision to make. I can either just pass these cells randomly and just let them go, or I can start marking that CLP, or that clipper bit, the cell loss priority bit, which would say that if there is congestion down the road, drop this - this will be, you know, eligible for discard first. And then finally, I could just - the policing function could also say, "I'm just dropping these cells on the spot, because this person is causing too much congestion at my layer." So that would be an example of isolating the connection - the congestion at that one single point. So, in this connect - in this scenario, we have our policeman up there, our UPC. And basically, as I said before, the policing function can either pass, or mark the clipper bit, or simply drop the cell on the spot if there is congestion. Generically, or I should say, in the public UNI space, this UPC functionality is also known as GCRA, or Generic Cell Rate Algorithm. So that's worth mentioning, because sometimes if you're negotiating with your public service provider, you may have to find out, you know, what the GCRA parameters are and things like that. So moving along with traffic management, there's this concept of tail packet discard, and the way the tail packet discard works is this: tail packet discard works such that when cells are passing through the switch and when congestion starts to be seen, the switch will then make a decision to start dropping cells. Well, rather than just start dropping cells randomly, because we saw what can happen there with that congestion collapse scenario, the switch has to be equipped to be able to discard cells all from the same bad packet. So, that's the concept with tail packet discard, is dropping all the cells from the same bad packet, rather than just dropping them randomly. And there are basically - and this would be, this is kind of a Cisco commercial here, a couple of Cisco's ways to deal with traffic management in the LightStream 1010 line. We have two different mechanisms basically to deal with this. We have this concept of Intelligent Tail Packet Discard, or ITPD, which says not only - it's kind of a, you know, it's tail packet discard which I just mentioned, which basically will drop all the cells from the same bad packet, but in addition, because this is AAL5 data traffic, it will take that last cell bit and it will turn the clip - clipper bit to zero, send it to the destination so the destination knows that, okay, all the other cells that were involved in this stream were dropped previously. But now what you can do is put together what you got, and then go back to the source and have them resend what you need right away, rather than waiting for retransmission timers and so forth to set to time out and whatnot. So that's the concept of intelligent tail packet discard. And then secondly we have this concept known as early packet discard. And what early packet discard does is it allows you to set up, basically, policies within the network, and thresholds, which say, "If this threshold is met, this threshold of congestion is met, then based on this policy, I want to start dropping cells from this type of traffic." So, this is the concept of early packet discard. So early packet discard tries to deal with congestion before it becomes a problem, so proactively combating congestion, versus tail packet discard, which says, "Wow, there's a lot of congestion, I better kick into ITPD mode," if you will. So these concepts are both known as - the combination of these is known as what Cisco calls UBR+, or Unspecified Bit Rate Plus. Now when we talk about - this is a good illustration of how this works and why this is very important, this concept of, you know, intelligent packet discard and intelligent tail packet discard, and so forth. Essentially on the top here, we see that maybe we're getting more cells through the switch, however the problem is that when the cells get to the destination, how many are useable if when you put them back into the packet format there are some cells missing? They're going to have to ask for a re-transmission. So essentially the bottom piece of this diagram here, which shows the switch with intelligent packet discard, it just simply dropped everything from that blue stream, and just tried to concentrate on the red and yellow stream. And incidentally, in the long run, what we've done is we've maximized what's called "goodput," or the number of useable packets that reach the destination. So incidentally, it's very important when looking at ATM vendors it's not just cell-in, cell-out, how fast can you switch cells, it's really a concept of being able to take advantage of these traffic management techniques to maximize goodput. So finally the converse of traffic policing would be traffic smoothing, or traffic shaping if you will. And essentially where you see traffic shaping is on the egress switch going from your private ATM network into the public ATM network. So essentially what you can do here is, you can take very bursty traffic that might be in your public - your private ATM network, if you will, and you can shape it such that even though it's going crazy back here in the private arena, when it gets out into the public ATM network it's moved out there very smoothly in a very contiguous manner such that it can comply with whatever your public ATM network has given you as far as the generic cell rate algorithm and so forth goes. The method I want to mention very quickly by which the switch will actually enforce the traffic smoothing, the traffic shaping, the policing and so forth, is this concept of the leaky bucket algorithm. That is a standard, and you can find more information on that on the ATM Forum. It gets a little bit more in depth to this talk than I wanted to get, but essentially the leaky bucket algorithm is a way to use that - the peak cell rate, and the maximum burst size, and things like that, in order to make sure that traffic is passing through the switch at the specified rate. So that's the leaky bucket algorithm in a quick nutshell, and as I said before I have a listing at the end of this talk of a bunch of Web pages on which that is mentioned as one of them. So we've talked a little bit about some generic traffic control techniques for packet discard, and now what I'd like to do is talk briefly about these available bit rate congestion feedback mechanisms that are in place in ATM networks. Basically, these congestion feedback mechanisms use what's called Resource Management cells, or RM cells, which are basically just cells that are dropped out onto the network as "control" cells. So in that PTI field, in that first bit, where we talked about whether or not it was user data or control data, the RM, if it's an RM cell, that control - it would be indicated there as a control cell. So at any rate, there are basically four flavors of this feedback mechanism that we're going to talk about. There's EFCI market - marking rather, Explicit Forward Congestion Indicator marking, and then there's relative rate marking, and then there's explicit rate marking, and then there's this concept known as Virtual Source/Virtual Destination, also known as VS/VD. So we'll go through each of the these right now. With regard to the first one that I mentioned, the EFCI marking, the Explicit Forward Congestion Indicator marking. What happens here is we have a source workstation which forwards a cell through the ATM network and as the - as that cell traverses the ATM network in a forward direction, the - if the switches along the way start to experience congestion, what they'll do is they'll set the congestion indicator and the - so those are now known as - the EFCI is set on those cells. As those cells then traverse the destination workstation, if you will, that destination workstation has the ability to drop out those RM cells onto the network in a backward direction, so that now these resource management cells when they reach the source, the source will say, "Oh, the destination's telling me that there is a problem because there is congestion in the network." Well, then the source can start sending slower and whatnot, but as you can see here that this feedback loop is really large, and there's a lot of burden on the destination to drop out these resource management cells. So you know, as it's illustrated here, it looks good on paper, but I sometimes wonder how effective it actually is, because by the time the congestion indicators reach the source to slow down that congestion problem could have gone away. So that's one of the shortcomings of EFCI marking, although you do see it used. Secondly, and a little more effectively, is this concept of relative rate marking. And the way that relative rate marking works is this: essentially if there is congestion experienced, either in the forward or the backward direction, the switches can send RM cells, they can just drop RM cells into this stream in a backward motion saying that there is congestion. So we're kind of shortening the feedback loop a little bit more. So now the onus is no longer on the destination to drop out the RM cells, but now the ATM cells in the cloud can actually drop them out for the source to be aware that there is congestion and it should slow down. So that's relative rate marking. And then finally we have explicit rate marking which takes us to a whole other level, which gets very fancy, whereby if there is congestion, you know, starting to be experienced in the network what can happen at this point is the ATM switches can now drop out RM cells in both the forward and the backward direction. And not only can they just send out these RM cells that have a generic, like, "Oh there's congestion," but they can say, "There's this much congestion experienced. You, Mr. Destination, need to slow down this much," or, "There's this much congestion, you, Mr. Source, need to slow down this much." So being able to say, the switch being able to indicate exactly how much the source and destination need to slow down in order to maintain this flow control. And then finally, we'll see that this concept of congestion feedback really shortens that congestion feedback loop down when we get to VS/VD, Virtual Source/Virtual Destination. Essentially what happens here is the feedback loop is broken down between two switches within the ATM cloud. So in this case the two ATM switches in the middle will talk amongst themselves to try to combat congestion at an even closer range. Now, what I'd like to mention here is that this congestion feedback mechanism for VS/VD, this is mainly for wide area networks where you might have, you know, a sprawling amount of ATM switches. VS/VD is actually supported on the StrataCom line of Cisco ATM switches, whereas the relative rate marking and EFCI marking and so forth are seen on the LightStream 1010 campus ATM switches, if you will. So, that's really the differentiator. And then what always come to my mind is, you know, when you start looking at different vendors and overhead taken it's kind of like well, do you get into a situation where you're spending more time trying to proactively combat things versus, you know, spending more CPU cycles on that, versus spending it just on moving cells faster. So there becomes this diminishing return that, you know, that different vendors have to reach. So I would urge you that if you did want to use these congestion feedback mechanisms, you know, no matter who the vendor is, is to make sure that the - this - there's a good level there of CPU versus what you're trying to avoid in the first place. Finally, with regard to traffic control techniques is the concept of how buffers work in an ATM network, and right here I would just want to quickly reiterate the difference between a frame switch and a cell switch with regard to buffers. Essentially, in a frame switch, or a packet switch, buffers can be distributed on a per-port basis and you just need big buffers to combat congestion and whatnot, and head of line blocking and that sort of thing. With an ATM switch, however, usually what you'll see is that the buffers are centrally located. And the reason is is that now when a pack - when a cell actually traverses a cell switch, the buffers are not just FIFO buffers, where it's first-in first-out for example, but rather it's this concept of being able to take traffic mixes of CBR, and UBR, and VBR, and whatnot, and being able to accommodate one priority traffic over another. And having a centralized cell buffer pool, if you will, is one way of doing that. So that's an important thing to note with regard to buffering. So moving along now, we'll talk now about some of the ATM transport standards that are available today. And first we'll start talking about the - we'll talk a little bit about the ATM Forum and where that started. Then we'll talk about the ATM UNI. There is UNI 3.0 and 3.1 and 4.0. And we'll talk about the ILMI address management, and then finally we'll talk about the ATM NNI. So first just to take note, the ATM Forum was actually founded in the fall of 1991, and Cisco, along with several others, were co-founding members, if you will. It's now a worldwide forum with over 700 members. And the main works that they have come out with in the past several years are the UNI and NNI signaling, known as UNI 3.0, 3.1 etc., and PNNI, and LANE, LAN Emulation, and MPOA, Multi-Protocol Over ATM. Those are examples of what the ATM Forum has worked on. And finally, on this slide we also see a listing for the ATM Forum Web page, which I would urge you to become, you know, become active on that page if you're interested in the trends with regard to ATM. There is a monthly newsletter that comes out known - they call it 53 Bytes. Go figure. And so the 53 Byte Newsletter comes out monthly and I would urge you if you want to keep up with the specifications that are in ballot right now and whatnot, that is a good one shot publication to get. So when we talk about ATM transport standards, let's first talk about - we talked about the UNI in a very generic way, the way that, you know, it was a user workstation talking to an ATM cloud, if you will, or non-ATM device talking into an ATM switch. So, at any rate, we have the UNI 3.0 and 3.1 as two ways that this is defined. It should be noted that 3.0 and 3.1 are not interoperable. So if you're using, obviously, 3.0 in your network, you want to make sure it's 3.0 across the board. And the reason that they're not interoperable, and you'll hear bits and pieces on this, but basically UNI 3.0 uses data link signaling protocol known as Q.SAAL, whereas the 3.1 standard uses the data link signaling known as SSCOP, or Service-Specific Convergence Protocol. So they are not interoperable is the main thing to get there. When we talk about the ATM Forum and we talk about the UNI, it's important to - one of the things that we really need to appreciate about what the ATM Forum has done for us is this concept of automatic address management. So, here for example is an example of an ATM address, and this is known and as NSAP address, which is 20 bytes long, or 40 digits. And Network Service Access Point is kind of the - an OSI term that kind of applies to the way that this - the ATM address is built. But at any rate, there are several types of ATM addresses out there. There's this NSAP address which is used for private ATM clouds, if you will. And then there's a public address space known as E.164 addresses, which are 15 digits long. And then - so what we need is, between the public and the private sector we need some kind of mechanism to tie them together. So there is a standard known as E.161 that will basically translate between our 40-digit NSAP addresses, and our 15-digit E.164 addresses. So at any rate the - moving right along here, let's just get an idea of what a real NSAP address look like. In your network what would a real NSAP address look like? Well, this is what it would basically look like, and I've broken it down into this ATM prefix and then the MAC address. And then there's that - the yellow area there that's known as the selector byte. And incidentally the selector byte is used differently by different vendors, and if you're using a Cisco product, one thing to note is that the selector byte can be a good indicator of what sub-interface on the router switch is being used. So that's a good troubleshooting mechanism there. But at any rate, you have this ATM prefix, and then the MAC. And the MAC address is just really the burned-in MAC address of the end station. So when we look at this NSAP address, and we think about how does that NSAP address get to the end station? Well, essentially - I myself would not want to go to each end station and type that in, and I don't think any of you would either - but essentially what the ATM Forum has done is within the UNI spec they have penciled in this concept of ILMI automatic addresses management, Interim Local Management Interface auto address management. And the way that this works is that the end station is aware of its MAC address, its burned-in MAC address, and the end station will then talk to the ATM switch over a well-known VPI/VCI 0.16, and it will say, "Hey, Mister ATM switch, I know my MAC address. Can you please send me my ATM prefix?" The switch will then, via ILMI, send back the ATM prefix to the end station. The end station will put together the ATM prefix with its MAC address, and then tag on the selector byte, and then there you have it. You have the ATM address configured on the end station without manual configuration. So, the ATM Forum has really saved us from having to go around and type in a 40-digit address per ATM end station. That's very key in this whole development. One thing that is worth mentioning here is that UNI 3.X or 3.0 and 3.1 - there are two basic types of connections. There's a point-to-point connection, it can be uni-directional or bi-directional, and that's all straightforward. However, UNI 3.X becomes a little convoluted when we start looking at point-to-multipoint connections. Because ATM is a connection oriented network, this can become kind of a problem point in an ATM network. And with UNI 3.X we have a root or a - the main device over here, which has then several leaves coming off of it, maybe in the case of a multicast. And in this case, in UNI 3.X applications, each - when a leaf wants to join a - there's no concept of group addressing, so the root has to incrementally add the leaves that want to be part of like a multicast, if you will. So this can be - this can present somewhat of a problem and it is addressed in UNI 4.0. Essentially, UNI 4.0 is basically an arm of another document known as signaling 4.0. So we have signaling 4.0, which contains UNI 4.0 and also our friend traffic management 4.0. And so traffic management 4.0 would be things like the CBR, VBR, and that sort of thing, and peak cell rate, and etc., the traffic descriptors. UNI 4.0 is another flavor of UNI, if you will, that basically has support for multicast. So we can now - we now have a concept of group addressing, and a concept of leaf initiated joins. Additionally with UNI 4.0, Quality of Service definitions will be able to be applied at the virtual channel level. So, better Quality of Service definitions will also happen with UNI 4.0. And UNI 4.0 is a standard today, it is being used. And it should be mentioned that UNI 4.0 is part of what the ATM Forum calls the Anchorage Accord. And what that means is that other protocol, other UNIs that will follow UNI 4.0 will be backward compatible with UNI 4.0. So, we've talked about UNI now and all of its flavors. Now I'd like to talk about the NNI, and we basically have two flavors of the NNI protocol that were developed by the ATM Forum. We have IISP, or the Interim Inter-Switch Protocol - Interim Inter-switch Signaling Protocol I should say. And that's also known as PNNI Phase 0. And then we have the dynamic routing protocol known as PNNI, just regular PNNI phase one, which is the one that we - it's more dynamic, takes advantage of Quality of Service. So, prior to talking about that, just to draw a comparison again with our packet-based networks, traditionally in a router-based network, shown here, you might use protocols such as RIP, and IGRP, and OSPF, and EIGRP, in order to determine the best path through the network. And each of those different routing protocols for TCP/IP has different algorithms in place and different types of techniques that they use in order to keep track of IP routes and update IP routes and whatnot. So, if we were going to make a comparison with ATM, really these - this IISP and PNNI are really just different ways to do ATM-based routing, if you will. So that's really - I just want to make that distinction that - just so that we know that these are really like ATM routing protocols. That's the way that I think of it. When we talk about first - IISP, or Interim Inter-switch Signaling Protocol, it gets a little convoluted. And basically, the way that IISP works is you define static routes in the ATM switches, and you can have multiple  routes, going between switches, from your source A to your destination B. And what then happens is it is dynamic in that when the call is actually set up, even though these - the connection between the switches is an NNI connection, they'll use this forum of UNI 3.0 and 3.1 signaling in order to bring up a call based on the static routes that were put in from the ATM perspective. So, really this was just a way for the ATM Forum to say, "You know, we're not going to be ready with the real PNNI for a while, so let's take advantage of what we do have, which is UNI, to build the routes - to actually build the connections dynamically but having the routes there statically." Incidentally, IISP is very effective for smaller networks and whatnot, and also for networks that aren't yet ready to take advantage of Quality of Service, because IISP offers no Quality of Service. With PNNI, PNNI Phase I, which is where we are today, essentially PNNI is a routing protocol in that it will find you the best route through the network, but not only will it find you the best route or, you know, be there for reachability but it will also work as a signaling protocol. And when I say it works as a signaling protocol what I mean is that it can also gauge and route cells through the network based on Quality of Service definitions as well. So, when we look at PNNI as a routing protocol it looks very much like OSPF. There are a couple of elements of PNNI that are analogous to OSPF. Starting with a PG, or a peer group - a peer group is a set of switches that interrelate in the same way that maybe an OSPF area might relate in OSPF terms. And then there's a concept of a peer group leader, or a PGL, which is in charge of talking - of this area talking to everyone else's area. So the peer group leader could be analogous to the designated router, if you will, within OSPF. Or the area border router, or the ABR, in OSPF. So the other thing that makes PNNI look very much like OSPF is just the fact that it works as a link state data base. So for example, it's a link state routing protocol in that each switch will keep a copy of all the other switches' data bases within its own - within its own data base such that it always knows where - it has a full map of the network, if you will. Rather than hop by hop, which would be the case with RIP or IGRP for example. So this is how PNNI - this is, you know, a very rough way that PNNI looks and it can be very hierarchical, so it can be very powerful. You can get something like a hundred different hierarchies within PNNI and the reason is is that that incept address is so long that you can accommodate several different hierarchies within there. One - so we've talked about now PNNI as a routing protocol and how it really looks and smells like OSPF. Now as a signaling protocol, where Quality of Service is brought into the equation, what we have is a - this concept of call admission control, which I've mentioned before, whereby if a connection is made from the source to the destination in - during the connection or the call setup phase this call admission control will happen, whereby the different switches in the network will negotiate among themselves to make sure that they cannot only provide the route to the destination, but that they can provide the Quality of Service that's also being asked for by the source. So let's say we meet - we reach a point in the B portion of this network, B.3, and all of a sudden that switch says, "I do not have enough buffers," or, "I do not have enough port bandwidth to be able to handle this connection in this way." Then what will happen is this process known as crank-back. And what crank-back does, it will crank back the connection that was made back to the ingress point into that peer group B and it'll reroute the call through an alternate route. It will reconnect the call through an alternate route that can accommodate the Quality of Service parameters being asked for. So this concept of crank-back and rerouting is very important, and this all happens during the call setup portion of the call. So, that was PNNI in a nutshell. And now what I'd like to do is talk about the crux of some of the ways that we can keep our legacy local area networks in place, or our legacy campus networks in place while still utilizing some of the powers of ATM within the network. So, some of the - we'll first talk about some of the challenges with, you know, maintaining what you have and integrating ATM into a solution, and then we'll talk about some of the standards that are more prevalent today, are more noteworthy, such as LANE 1.0, LANE 2.0, and then finally MPOA, or multi-protocol over ATM. So first just to touch briefly on the challenges that are involved. Basically there are three challenges that I see. The first one is there is no real API or application programming interface that is made to accommodate ATM traffic just yet. So there's no - there's no real, you know, application program interface that is going to accommodate ATM addressing, or is going to accommodate Quality of Service and that sort of thing. So that's the first kind of fallback, if you will, or the first hurdle that we're going to see. The second one is that because ATM is an NBMA, or a Non-Broadcast Media Access, and we're mainly working in campus environments with chatty protocols such as IP and IPX there has to be some kind of mechanism in an ATM network to be able to handle broadcasts and multicasts very efficiently. So broadcast handling is another hurdle that we need to overcome when we start introducing ATM into our traditional campus networks. And then finally a picture to kind of illustrate that there are several layers of addressing now at work within the ATM - within the network itself. So we have our regular burned-in MAC addresses at some point, and then we have our network addresses on our end stations, like IP, or IPX internal network numbers, and then we have our ATM addresses. So, we need now just yet another layer of address resolution, if you will. So these multiple layers of addressing also need to be addressed. And the way that these problems are addressed are through several standards. The IETF came up with two standards - oh, more than two but the two that are relevant to this talk are RFC1483 and RFC1577. RFC1483 is basically a way to set up static routers within an ATM network and it's used very widely today, actually, in smaller routed networks, for example, but we're not going to touch too much on that. Secondly, there is RFC1577, which is classical IP and ARP over ATM. And this - classical IP and ARP over ATM, or 1577, is very useful in IP-only networks that are not broadcast intensive and that are not very, I would say - that don't need real high network availability because, for example, if a component of RFC1577 goes away like something called an ARP server that does this IP address to ATM address resolution, if that goes away on the network there's no provision for a backup, for example. So I've decided to focus mainly on LANE, LAN Emulation, and MPOA, or Multi-Protocol Over ATM, in this talk today. So starting out with LANE 1.0 which has been out there for quite some time - there are a lot of proven networks using LANE today. Essentially, what happens with LANE 1.0 is that you can have your legacy network - maybe you'll have a, you know, a switch with a bunch of Ethernet clients on it, like a Catalyst 5500 for example, and then you'll have one card within that switch that is known as a LANE card, and it may have an OC-3 pipe into an ATM switch that - so in other words, the Ethernet clients don't even know that ATM is running out there. So it's a really good way to preserve your current infrastructure for example. So when you - when we talk about LANE 1.0 we have to make sure that there are LAN switches that have an ATM adapter, if you will, that talk LANE, that can do the translation for the Ethernet clients. Or if you have a server that you want to speak LANE you would have to make sure that the NIC card in the server supported LANE directly. And, again, if you had a router that you wanted to support LANE it would also have an ATM card that would be - that would operate the LANE protocol. So, how does LANE actually work? Well, there's several pieces of terminology, believe it or not, within LANE that need to be understood first. The first is this concept of a LAN Emulation client. And a LAN Emulation client is just any ATM - ATM attached device in the LANE cloud that requests services throughout the network. And when we talk about the services that - this brings up the next few pieces of LANE terminology. The services are the LECS, or the LAN Emulation Configuration Server. And the LAN Emulation configuration server is just a way for clients to be initialized as they join a LANE network. And then we have the LAN Emulation server. And the LAN Emulation server's main job is to do the ATM address to - or MAC address to ATM address resolution. And then finally we have the Broadcast and Unknown Server, or the BUS - and usually the LES/BUS work together. And the broadcast and unknown server is, you guessed it, it's for broadcast and - broadcast packets, and also for packets which are - have an unknown destination. So that's the broadcast and unknown server. Incidentally, when I was talking about the LES the - basically the job of the LES is to translate MAC address to ATM address. This is what makes LANE usable for multiple protocols is because now we're not doing IP address to ATM address resolution, but rather we're doing MAC address to ATM address resolution. So, just wanted to kind of clarify that. The best way to talk about LANE is really to have an example. And essentially what happens in a LANE network is there are several virtual channels that are created - or virtual channel connections that are created, and this is all done automatically over SVCs. SVCs, or Switch Virtual Circuits, are a prerequisite for this technology, and essentially what happens is one client will - if a client wants to establish a connection with another client what that client will do is first it will talk to its LECS, or the LAN Emulation Configuration Server, and that LAN Emulation configuration server will say, "You, Mr. End Station need to be in this emulated LAN, or ELAN, and this is your - the address of your LAN Emulation server that you'll be working with today." And then the LAN Emulation client says, "Thank you very much," and it makes a connection with the LAN Emulation server, and then as the LAN emulation server is negotiate - or trying to resolve, rather, the ATM address to - the MAC address to ATM address resolution, the connection is also made to the broadcast and unknown server to start getting packets forwarded out to the destination until the resolution is made. Once the resolution is made we get to our end goal in LANE, which is basically what's called a data direct VCC, or a data direct Virtual Channel Connection, between the source LEC and the destination LEC. So essentially, all these steps have to happen and there're all these different types of VCCs that have to be available in order for just one client to talk to another client. But within ATM this is an important specification when we start to look at preserving our current network and our current Ethernet LANs, if you will. So LANE 1.0 does have some deficiencies, if you will, that are addressed in what was just ratified as LANE 2.0. And LANE 2.0 is made up of two components, one of which is done now. It's made up of the LUNI spec and the LNNI spec. The LUNI spec, or LUNI spec, has been completed. It was completed in May of last year, right around the MPOA spec because they are - MPOA, a prerequisite for MPOA, is this LUNI spec. And essentially LNNI is still being worked out. But essentially what LANE 2.0 is giving us is first of all LANE 2.0 is kind of the backbone of MPOA, or one of the components of MPOA I should say, not really the backbone. But in addition what LANE 2.0 will give us is this concept of better efficiency of virtual channels. So whereas we saw all these different channels had to be built in a couple slides back we had all the spaghetti of VCCs in the middle of the cloud while this data direct VCC was trying to be made, the LANE 2.0 spec will make better efficiency of these virtual channels. In addition, the LANE 1.0 spec has no component right now for Quality of Service. So sometimes it's kind of a misnomer in an ATM network when someone chooses LANE over Gigabit Ethernet, they say that they're doing it because they get Quality of Service. Well, in a LANE 1.0 environment you're not getting Quality of Service. But the idea is that in LANE 2.0 there will be Quality of Service, so if you build it today you can think that Quality of Service will be there tomorrow. And then there's a concept of a Special Multicast Server, or an SMS, that is also another component of LANE 2.0, whereby the dispersion of multicast will be done in a more orderly format rather than just having the BUS do all the work, or the Broadcast and Unknown Server do all the work. And then finally there's this concept of server redundancy. And essentially, if you think about our ATM example, if our LECS, or our LAN Emulation client - I'm sorry, our LAN Emulation Configuration Server went down, no other clients could join their specified ELAN because the initialization server has gone down. And incidentally, if the LES/BUS goes down, no two stations would be able to talk to each other because they can no longer do the MAC address to ATM address resolution or broadcast and unknown cells could not be transferred across the network. So in other words, there is no server redundancy built in in LANE 1.0. Commercial break for Cisco right now is that with LANE 1.0 we actually do offer a protocol called SSRP, or Simple Server Redundancy Protocol, that does provide for a backup mechanism, if you will, if the LECS or the LES/BUS should fail. So Cisco as a, you know, as a semi-proprietary solution, although we do interoperate with other vendors with SSRP is - does provide for a mechanism for redundancy in a LANE environment today. In addition, the LANE 2.0 spec is also providing for server redundancy and, incidentally, the ATM Forum server redundancy protocol looks very much like Cisco's SSRP. I'm not sure why, but at any rate it couldn't be because there's a - the chairman of the committee is working for Cisco, no, no. At any rate, moving right along here we said before that LANE 2.0, or the LUNI portion of LANE, is used in multi-protocol over ATM. Well, what is MPOA? Essentially, what MPOA does is this: if we were to look at a LANE environment as it were, in order to go from one ELAN or one virtual LAN to another virtual LAN, those packets or cells would still have to traverse the router in order to make that Layer 3 decision, for example at the TCP layer, the MAC rewrite, and the IP checksum, and the TTL decrement would still have to go to the router. So, the router obviously in this situation could present somewhat of a bottleneck. And so things like MPOA were developed such that now we have this concept of cut-through routing. And with MPOA the way it works is this: there is a multi-protocol client, Multi-Protocol over ATM Client, known as the MPC, and a multi-protocol over ATM server. And they work in tandem in order to provide the cut-through routing. So let's go over a little bit about what these components are and then we'll go through a quick example. The MPS, or the MPOA server, is actually - don't tell anyone but it's really just a router, and basically the MPOA server which can just be a regular Cisco 7500 router, if you will, will run regular IP routing protocol such as IGRP or OSPF or whatnot, and what it does then is it will basically provide the MPOA client with viable routes through the network for destinations. So the route server can just be there to provide forwarding paths to the MPOA client, or it can be there as what's called the default forwarder. And essentially the reason you would want a default forwarder is that, for example, if you had a short-lived flow in the network, such as a ping or something to that effect, where - or, you know, a DNS query, then in that case you would want a default forwarder such as a router in the picture in order to quickly just take care of the routing decision and the routing of the packet without having to go through the whole downloading of a route from the MPOA to the MPOA client and so forth. So that's the job of a default forwarder, and usually the default forwarder will be disguised as a router. And then we have the MPOA client. And usually the MPOA client would be something like the 5500 LANE card running the MPOA client software. And so this edge device is there such that when the Ethernet clients request, you know, want to get from source to destination and it - normally what would be a Layer 3 hop through a router, the MPOA client now will request the routes from the server, the MPS, such that it can make that Layer 3 decision on the spot without having to forward packets to the router. And the same thing happens within the MPOA client. There is still a MAC rewrite. There's still a TTL decrement. There's still an IP checksum. So there's still IP routing going on there, but it's happening - in Cisco solution we're going to do it in hardware and by the time this video is out perhaps Cisco solution will already be out as well. But at any rate, the MPOA client functionality will be done in hardware so it will be done very quickly. Finally, also seen as an MPOA client, or a viable option for an MPOA client, would be an enterprise server. So, for example, if a NIC card or a NIC vendor decided to make their server be able to talk MPC then that server could also work as a MPOA client and also be kind of a pseudo router in the network. So those are some different components of MPOA. And then finally just to look at a quick example of what MPOA would look like. MPOA uses this concept of query response. And what query and response is, basically, is that if there's an end station off of an emulated LAN on a switch and it wants to go from subnet A to subnet B in this example, the client, the MPOA client, shown as the switch in the bottom of the diagram, where emulated LAN A is, would actually query the route server, or the router if you will, to find out the best - to find out what the Layer 3 information is before it could traverse the ATM cloud. So, in essence the LUNI spec is used in order for this - for these devices to talk amongst themselves and build the route tables. And then in addition the NHRP, or Next Hop Router Protocol, is also used in order for these routes to be forwarded through the network to the edge devices. And really the result is that the packets would no longer have to traverse a router if they want to go from one subnet to another, but now there's this direct cut-through virtual channel that is built in order to accommodate that Layer 3 traffic. So, now we've taken it from - we've talked about all the ATM fundamentals. We've talked about UNI. We've talked about NNI. We've talked about the ATM cell header. We've talked about PVCs and SVCs and all the ATM service categories, and traffic management, and the different transport standards with regard to UNI 3.X and 4.X, and PNNI, and some campus internetworking terms. So it's been a very well rounded session if you will, I think, and but essentially here are some ATM references that you can refer to with regard to different places you can look for further information. And on this slide I would say that the Indiana University Web page that's listed here has a lot of good Q&A type - question and answer type forums that they allow you to send questions in and things like that. So that's actually a really good Web page, as well as the ATM Forum Web page as I mentioned before. So that will wrap up the talk. Thank you very much for your time and if there are any questions stemming from this, my e-mail address is seast@cisco.com. Thank you very much.  </BODY> </HTML>